Light ROM 4/Light ROM 4 - Disc 1.iso/text/maillist/1996/032296.doc/[e-mail] _Sun Mar 24 13:56:29 1996.msg

Internet Message Format | 1996-04-02 | 5KB

Received: from e55.webcom.com (e55.webcom.com [206.2.192.66]) by keeper.albany.net (8.7.5/8.7.5-MZ) with ESMTP id NAA01761 for <[e-mail]>; Sun, 24 Mar 1996 13:56:27 -0500 (EST)
Received: from localhost by e55.webcom.com with SMTP
    (1.37.109.15/16.2) id AA057893727; Sun, 24 Mar 1996 10:55:27 -0800
Date: Sun, 24 Mar 1996 10:55:27 -0800
Errors-To: [e-mail]
Message-Id: <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Originator: [e-mail]
Sender: [e-mail]
Precedence: bulk
From: [e-mail]
To: [e-mail]
Subject: Re: Collision Detection
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Status: RO
X-Status:

In a message dated 96-03-23 23:16:09 EST, you write:

>And the results often occur where the character or object is suddenly in
>the air or partially buried.
>  Is there some specific reason why object/surface collision detection is
>so hard to implement in 3D vs. 2D?  In video games, it is really trivial
>to detect collisions between sprites and backgrounds or other sprites.  I
>would think, from my limited programming skills, that since a surface
>exists in 3-dimensional coordinates and the object exists in 3d
>coordinates, that it would not be difficult to have a routine where a set
>of points coincides with another set of points.

     Well, let me see. First, 3d collision is a little more tricky than
sprite collision, but implementing it is fairly easy - we have a real time
physics engine in our 3d environment now. Anyway, the main problems I see
with a solution like this is not so much detecting the collision, but knowing
what to do after you've found it. For example, take a person walking across a
rolling hilly landscape (my favorite kind..). First, you'd have to define
what is important to check against, and what is not. (Say, the ground, the
particle grass, or a rock..). Does the player walk on top of the grass? no,
he should trample it because of his weight. So say grass isn't in the
picture, to make it easier. Now you still have the problem of what to do with
your feet when you hit the ground. Should the walk cycle just be raised up if
he hits the ground? No, he should change his walk cycle to walk up the hill,
not just float higher. Yet, for something like a vehicle, you wouldn't want
to change the "walk" cycle, but just rotate the vehicle.. The number of
problems you run into is more than you might think. Although many programs
have overcome these problems, and eventualy lightwave will too. Real3d, for
instance, alows you to assign rules to your objects and then it will
calculate how they should react to the landscape..

>  I notice most animators try to avoid close-ups with this type of
>situation (unless the surface is flat) by moving to shots of the upper
>torso or use long-distance shots where the lack of contact with the
>ground is not so noticeable.

     And don't forget the slidding feet sindrome.. PLEASE - will someone hint
to allen that the IK chains should go both ways! I should be able to move the
foot, and have the leg ajust, and I should also be able to lock down the
foot, and move the body, having the leg ajust..

>  I suppose programs like Impact are there to deal with this but is there
>some reason why Lightwave doesn't have this capability built-in? Or is it
>there in the envelope map and I just haven't figured out how to use it?

      Impact would help, but not on something like a human walk cycle, for
sure. Every step would require modification of the animation to make it
perfect..
     Perhaps I can suggest a workaround, to hold you off untill these types
of things are implemented.. Of the top of my head, try something like this..

     Load your landscape into modeler, Create a plane, or series of plains,
which are verticle, and intersect with your landscape in the direction(s) of
your walking animation. Booleen subtract the landscape from the plain,
leaving just the plane, with the path your object will travel in the bottom
of the plane.
    Now, remove the polygon leaving just the points. Next, link up the points
as a series of 2 point polygons (lines).
    Next, remove the polygon, leaving only the points. Select the points in
the direction of the walk path, and create a spline. Run the path2motion
plugin (or arexx macro) on it. Save out your motion.
    Go into layout, parent your walking man to a null object, and load the
motion you saved in modeler into your null object. You'll probrobly have to
scale the motion so he moves at the correct speed across the landscape. Then,
change all the spline tentions to linear.
    Next, parent that null to a new null object, call it man_ajust or
something. Then go to each keyframe, and ajust the mans rotation so he walks
up or down the landscape corectly. You may have to tweak some in-between
frames, but basicaly you man will walk across the landscape and not slip
though it, or float above it..
     Geeze.. maybe I should have just done this myself (to see if it works)
and written a LWpro tutorial.. oh well..

    Hope this helps.. Oh, it's much easier with something like a vehicle..